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1.  INTRODUCTION 

'I'lic  Inlcr-Tool  CU>mmunicalion  I’acilily  (ri’CI*)  was  spcciTicd  under  S'rARS  'lask 
Qll.  A  VAX/('A1S-A  implemcntalion  of  llie  core  I'l’CT'  facililies.  a  demonslralion 
of  ihe  ITCr  u.sing  exisling  tools,  and  this  final  report  were  completed  under  STARS 
Task  BR67.  'I'liis  reports  describes  the  1T(!1‘,  the  design,  the  implementation,  and  the 
demonstration  performed.  More  detailed  documentation  and  information  about  the 
ITCr  and  the  demonstration  tools  can  he  found  in  the  ITCT  Version  De.scription  and 
in  the  source  code  for  the  ITCT'  packages  and  for  demonstration  tools.  All  ITCT 
deliverables  ineluding  .source  code  and  reports  are  currently  on  the  Boeing  MDSC 
V.AX  under  the  root  directory: 

sy.s$usi-:r7(SC)iti-:c:iii.usi-rs.sabbuiii..itc'i-| 

The  file  eonlained  therein  de.scrihing  the  directory  organization  of  the  deliverables  is: 
|SOI-TI-.C'IIl.USI-:R.S.SABBUIII..ITC'l-inCTLVI-:R.SION_Dl-..SCRIITIC)N.ADS. 
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2.  C5!  {NIGRAL  Dl  iSCRlPTlON 


The  follDwing  a  general  cle.seriplien  of  ihe  ITCF.  More  details  can  be  t\)und  in  the 
file  IT('^_Ver^ion_Oe.^eription.ad^  and  in  the  package  specifications  and  bodies  for  llie 
delivere<l  software. 


The  rr(2’  permits  concurrently  executing  tools  to  cooperate  in  an  integrated  manner 
while  maintaining  their  high  degree  of  modularity  and  functional  independence.  'I’hc 
rrer  offers  a  layered  architecture  of  communication  services  which  may  be  adapted  to 
meet  the  require.ments  of  a  variety  of  tool  integration  strategies.  'I'he  principle 
conceptual  layers  are  streams,  stream  protocols  and  messages. 

The  rre^r  services  manage  the  complex  details  of  inter-tool  communication  and 
provide  conceptually  simple  and  ea  a  to  u.sc  interfaces  U)  the  tool  writer.  'I’hese  .services 
facilitate  the  integration  of  tot)ls  with  relatively  iTU)dest  effort,  including  existing  tools 
which  were  not  originally  designed  to  u.se  the  ri'CI-  packages. 

The  rrer  is  intended  U>  transfer  data  which  is  primarily  transient  in  nature  as  oppt)sed 
to  data  which  is  permanently  stored  in  the  environment  data  base.  Permanent  data 
should  be  handled  through  the  envitonmenl  object  management  .system.  Neverthele.ss, 
simple  tools  can  be  implemented,  u.sing  the  ITCr  packages.. which  alU)w  ijtc  connection 
()f  other  tools  to  files  (including  devices)  as  .sources  and  sinks  for  inler-tooi  diita. 

The  ITCir  is  also  intended  to  suppt)rt  ci)mmunicatlon  between  tools  executing  in 
different  CAIS-A  environments  that  are  connected  by.  a  gateway.  However,  this 
feature  was  not  implemented  under  task  BR67. 


-1 
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3.  rrci-  CONCl^FTS 


The  underlying  coneepls  of  the  rrC'l'  haye  been  derived  I'rom  a  number  of  source.s. 
The.se  inelude  UNIX  pipe.s,  plumbing  fixlure.s  and  fillers;  the  CAIS-A.  10  C'onneclion 
Mt)del;  and  various  Remote  Procedure  Call  (RFC)  facilities  and  stream  manipulation 
packages.  The  riUl.l)  environment  integration  mechanism,  described  by  Steven  Reiss 
of  Brown  University,  was  particularly  influential. 

3.1  Clients  and  (amneclion  (!enter.<; 

'I'he  focus  of  ITCr  t)peralions  are  server  proce.sses  called  connection  centers.  A  given 
rconneclion  center  may  have  tme  or  more  clients.  A  client  may  be  a  tool  (i.e.  a 
proce.ss),  or  a  gateway.  A  gateway  client  represents  other  clients  and/i)r  conneclii)n 
centers  on  a  remote  host  .system.  (Clients  communicate  with  one  another  via  the 
connection  center. 


The  first  step  in  using  the  ITCT  is  the  creation  of  a  connection  center.  .After  the  center 
has  been  created,  clients  may  be  connected  to  the  center.  C'onneclion  of  a  client  to  a 
connection  center  establishes  a  communicalion.s  channel  between  the  client  and  the 
center.  This  channel  is  called  a  connection.  (Mienis  may  be  connected  or  disconnected 
at  any  time.  Only  clients,  of  the  same  center  pjay  communicate  \viih..one,..aiu)lher. 
r.aeh  client  may  be  connected  to  only  one  center  at  a  given  lime,  ('ifenis  may 
communicate  through  the  connection  center  concurrently. 


3.2  Streams 


At  the  lowest  conceptual  layer  of  the  ITCl’,  data  is  passed  through  the  connection 
center  in  the  form  of  streams.  A  stream  is  simply  a  sequence  of  data  (of  indefinite 
length)  generated  by  a  client.  A  client  sends  data  by  writing  into  a  sire;im.  A  client 
receives  data  by  reading  fn)m  a  stream. 

The  flow  of  data  in  a  sire.im  is  uni-directional.  When  bi-directional  fl«)w  is  required, 
a  reverse  stream  called  a  reply  stream  may  be  used.  A  client  proce.ss  may  use  multiple 
Streams  concurrently.  The  flow  of  dal.i  in  eaeh  stream  is  independent  of  other 
^ unrelated  .streams. 

.Streams  may  be  u.sed  by  proce.sses  for  direct  communication  wiihijul  the  u.se  of  a 
connection  center.  Conneetion  center  facilities  are  built  on  lop  of  the  lower -level 
sirciim  .services.  Streams  may  al.so  be  u.sed  locally  within  a  proce.ss  for  communication 
■  between  tasks  without  the  jiverhead  a.s.socialed  with  .sending  sli earns  through  a  separate 
connection  center  proce.ss. 
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4.  Implcmcnialit)!!  Overview 


The  core  faeililies  of  ihe  ITC'!’  were  implemented  on  the  MDSC  VAX  machine  using 
V'AXAd.i  2.{)  and  Version  4.5  of  the  C'AIS-A  implementation.  'I’he  ITC’l*  .services  are 
prt»vidcd  a.'-  .i  collection  of  packages  containing  interfaces  which  ma>  be  called  by 
(  AlS  U)ols. 


The  principal  packages  implemented  are: 

Stream_10  -  Supports  all  low-level  .stream  operations  including  interprtK'e.ss 
communication. 

Te.\t_Stream_lO  -  Provides  the  interfaces  of  Ada  Te.\’t_l()  for  reading  and 
writing  .stream  data. 

Connection  -  Provides  interfaces  that  client  tools  call  to  interface  with  a 
connection  center. 


Conncciion_Ccntcr  -  A  generic  package  which  supports  the  instantiation  of  user 
defined  connection  centers. 


•  *s  * 

Distribution  -  A  generic  package  which  performs  general  disiribution  li.si 
management  functions  ft>r  instantiations  of  package  C-onnection_( ‘enter. 


Monitor  -  A  low-level  packages  which  is  used  to  manage  concurrent  acce.ss  to 
Streams,  This  is  an  internal  ITC’F  package  which  contains.no  tool  interfaces. 


.1 
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5.  OI-SIGN  PROBLI-MS  AN'I)  SOLUTIONS 

A.spctLs  ihc  rrC'L  impIcmciUation  which  prcscnled  significanl  technical  challcngCN 
\scrc  Uk  management  i)f  concurrent  accos  to  .streams  ami  the  interproec.v.  connection 
rc.sourcc.s,  ant!  the  mechani.sm  to  support  stream  copying.  Stream  copying  is  a 
rumlamental  1T(  'I '  concept  of  sub.stantial  power  in  affecting  the  distribution  t)f  .streams 
and  the  compo.sition  of  .sireams  from  other  streams. 

5.1  Concurrent  Acce.ss  to  .Streams 

'I'wo  problems  needed  to  be  addressed  in  the  handling  of  concurrent  access.  'Fhe  fir.si 
;\\as  to  develop  a  conceptual  model  that  would  make  a  correct  implementation 
conceptually  manageable.  The  .•*econd  problem  was  to  a.ssure  that  management  of 
concurrent  acce.ss  would  he  rea.sonal)ly  efficient. 

5.1.1  U.sing  Ada  Reiulc’/.vous 

Initial  attempts  to  achieve  a  conceptual  model  for  concurrent  acce.ss  were  f»K;u.Ned  «»n 
the  direct  use  of  the  Ada  reiule/.vtms  model.  One  question  was  how  tasking  should  be 
applied.  The  Ada  rendezvous  model  is  generally  applied  by  identifying  a  object  to 
which  c»)ncurrcnl  acce.ss  may  tvecur  and  then  applying  a  task  to  manage  the  o!)ject.  All 
acce.ss  to  the  object  is  then  accomplished  through  calling  entries  to  that  ^sk'.  Hence, 
one  attempt  to  the  solve  concurrent  acce.ss  problems  in  the  I'l’CT  was  to  have  each 
stream  be  managed  by  a  .separate  la.sk.  'Fhis  approach  was  eventually  rejected  becau.se 
it  wiiuld  require  a  large  number  «>f  tasks,  .straining  system  re.sources.  Al.so.  it  was  not 
clear  how  stream  copying  could  be  implemented.  Stream  ct)pying  would  either  require 
1)  stream -ta.sks  U)  call  other  .stream  tasks,  thereby  taking  themselves  unavailable  for 
satisfying  other  cttncurreni  acce.ss.  to  the  .stream,  or  2)  the  creation  of  addition 
copy -tasks  that  would  simply  read  data  from  one  stream-task  and  write-data  to 
another.  While  such  tasks  could  be  recycled,  thus  reducing  the  overall  overhead  of 
frequent  task  creation,  the  number  of  tasks  that  would  be  required  was  still  of  .some 
concern. 


.\nother  approach  to  using  rendezvous  was  Is)  define  a  single  task  which  provides  all 
.services  '.o  all  streams.  This  task  vv«)uld  serialize  access  u»  all  stream  operaiit»n>. 
HVhilc  this  approach  wtiuld  greatly  reduce  the  number  of  tasks  required,  it  had  .sonic 
disadvantages.  One  disadvantage  was  that  all  .stream  functions  vv'ould  have  to  be 
piovided  in  a  single  large  task  bmly.  In  order  to  modularize  the.se  functions,  calls 
would  have  to  be  u.sed  in  the  ACCl.PT  statements  of  this  task  body  adding  avidiiion.il 
overhead  (which  could  po.s.sibly  be  reducevi  through  the  use  of  PRAfJMA  INI. INI  ). 
.AlsvJ.  luiw  lo  interface  vviih  .liher  ta.sks  which  manage  transmi.ssion  of  .streams  over 
connections  was  not  clear. 


While  the.se  problems  prob.ibly  ctiuid  be  vivercome.  there  was  one  problem  that  was 
shared  by  ail  approaches  ih.ii  u.sed  Avia  reiulezvous  cwciusively:  every  operation  on  a 
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stream  would  involve  four  tasks  switchc>s.  Task  switching  has  certain  unavoidable 
overhead  oven  in  the  best  Ada  runtime  implementations.  All  "re^sicrs  must  be  stored 
and  loaded,  and  the  scIteduUng  algorithm  must  be  invoked.  'lliis  would  imply  that  an 
operation  which  is  to  write  a  single  byte  to  a  stream  could  have  an  overhead  on  the 
order  of  a  hundred  instructions.  This  overhead  could  be  signi|icanily  reduced  by  using 
buffering  to  minlmi/.e  the  number  of  rendezvous  r^uired  to  transmil'a  ^ven  amount  of 
data.  However,  this  would  only  help  in  the  .Pul  and  Get  functions  in  package 
Stream_IO.  'fhe  overhead  for  all  other  functions  would  not  b<?reduccd. 

•  -  jf .  .  ■ 

5.1.2  Using  Monitor.s  .  .  ■  /  ■  I  ■ 

*'  ■  -  . 

.An  alternative  appro«ach  was  to  apply  Hoare's  Monitor  concej^.  In  this  approach,  the 
•SCI  of  all  streams  is  considered  a  shared  resource  to  whichtacccss  is  control  via  a 
monitor  entity.  Whenever  a  task  needs  to  operat^  on  a  stream,  it  must  first  enter  the 
monitor.  Monitor  entry  i.s  queued  .so  that  only  one  task  can  c?Jccute  within  the  monitor 
at  a  time.  If  the  operation  cai.not  be  completed  hnnicdiateJy  {for  example  an  attempt 


to  road  a  stream  w! 


>'hich  is  temporarily  empty),  the  task  may  suspend  itself  on  a 
condition  variable  until  the  operation  can  be  completed.  When  a  task  suspends  itself 
within  a  monitor,  another  task  is  allowed  to  enter.  Kvcntually*  a  task  will  enter  which 
writes  to  the  stream  and  signals  the  condition  variable  upon  tfhich  the  su.<pcndcd  task 
i.s  waiting.  j 


5.1.3  Monitor  Implemenlulion 


Tlic  monitor  framework  was  very  helpful  in  sorting  out  the  concurrent  access  problems. 
However,  since  Ada  docs  not  directly  support  monilo.'-.s,  it  was  necessary  to  consider 
how  they  would  be  implcmcnlctl.  Wailing  mu-st  occur  when  a  task  attempts  to  enter  a 
monitor,  if  another  ia.sk  i>  using  the  monitor,  and  when  a  iask*mu.st  be  suspended  on  a 
condition  variable.  In  Ada,  tlic  only  way  lor  a  task  to  wait  ufllil  some  event  occurs  is 
Usrougli  a  call  to  a  task  entry.  .A  very  simple  and  direct  approach  to  lire  monitor  entry 
problem  is  to  use  a  simple  la.^k  which  alternately  accepts  a^  entry  call  to  enter  ilie 
monitor  and  an  entry  call  U»  leave  the  moniun.  'ITie  major  dr^vback  to  this  solution  is 
that  the  cycle  of  entering  and  leaving  the  monitor  would  W^uire  two  rendezvous 
involving  eight  task  .switches. 


However,  an  important  ob.scrvaiitm  is  that,  in  most  cases,  when  a  ia.sk  altcmpis  to 
cater  tlie  monitor  there  will  be  n«>  task  executing  in  the  monisof.  Tiias,  in  most  cases  a 
rende4vous  should  be  unnecessary.  In  the  ITCF  iniplcracnlalipn,  a  counter  which  can 
be  intrcmented/dccrcinenlcd  and  lesletl  as  an  atomic  operalibn  is  u^cd  to  determine 
whether  a  task  is  currently  executing  within  the  monitor.  A  rende?.vou.s  i.s  u.scd  to 
.'‘Ospend  an  entering  task  only  if  the  result  of  incrementing  tlie  counter  indicates  that 
aaoil'.er  task  is  alreadv  executing  inside  the  monitor.  Tins  strategy  rcduce.s  the 
overhead  of  monitor  entry  and  exit  to  a  few  inslroctions,  ^versus  the  hundreds  of 
instructions  lhai  would  be  e.\cculed  using  rendezvou-s  exclusively. 


Inter- Fool  (Tommunicalion  Final  Repor 


I 


D6J  3-2 1270 


iCS  773  4946  PA6E.C0r 


10 


11  ’31  IS:0S 


OCT  : 


CDRL  0U70 
TASK  BR67 


The  BOEING  Cohy?ony 
D613-21270. 

■  f 


CDRL  01270 


1 


*  '  ‘  0  * 

Tlie  leclmique  use^l  could  be  criticized  for  not  being  pure  Ada.  However,  the  only 

implementation  dependency  introduced  by  this  '.s.hniquc  is  tlVc  implementation  of  the 

atomic  counter  on' the  host.  Mosi  I'troccssors  hav^  such  an  instruction,  Other.s  have  an 

instruction  (such  as  a  test  and  set)  which  can  be  used  to  synthesize  an  atomic  counter. 

In  the  case  of  the  VAX,  the  "VAXAda  compiler  has  a  built-in. procedure  for  an  atomic 

counter.'  For  other  ho.sts  or  compiling  systems,  (i  may  be  lu^ccssary  to  write  a  small 

assembly  language.unit.  ?  • 


Jn  any  case,  the  dependency  is  isolated  '  within  a  'small  package  called 
rrolccted„C'ounlcr.  There  is  ho  dependency  on  the  Ada  run-tfjne  implementation.  All 
tasking  operations  arc  .still  handled  in  pure  Ada.  ‘  , 


5.2  Stream  Copying 


.  « 

Several  false  starts  woie  required  in  the  design  olStream  copying  before  a  satisfactory 
solution  w'as  arrived  at.  The  final  solution  was  to  place  an  it(j.m  rcprc.scnting  the  "tail" 
(i.c.  the  remainder)  of  a  copied  stream  in  the  item  queue  (|f  every  target  stream  to 
which  the  stream  is  copied.  These  tails  arc  kept  on  a  li.sl. 'Jiach  time  another  data 
buffer  is  added  to  tlic  .source  stream,  an  item  referencing  th|t  buffer  is  in.scrlcd  into 
each  target  stream  immediately  ahead  of  each  tail  (in  the  li.sf  of  tails)  for  the  copied 
stream.  This  effectively  copies  the  data  into  each  target  .slrcam'ai  the  appropriate  point 
within  each  of  those  streams.  WJtcn  the  copied  .stream  is  closo^,  the  tails  are  di.scarde<l 
since  no  further  insertion.s  of  data  from  the  copiec' 'stream  arc  Accessary. 


in  applicatiois  involving  large  streams,  the  amount  of  daia^  which  is  buffered  in  a 
stream  must  be  bounded  to  prevent  storage  resour’co.s  I’rom  bchig  cxiiausted.  Handling 
of  bounded  buffering  in  .stream.s  wa.s  problematic  due  to  the  copying  facility.  Initial,  it 
was  not  clear  how  to  account  for  buffered  data  which  has  bce|i  copied.  As  the  design 
of  the  copy  capability  progrc-ssed,  it  xva.s  decitled  that  buffers  would  be  copied  by 
reference  rather  tlian  by  value  for  efficiency  reasons.  The '^accounting  problem  of 
jdacing  boiiiid.s  on  buffering  was  then  solved  by  designating  lhi|  stream  to  winch  data  is 
originally  written  as  the  owner  of  that  data,  'I'hus^,  copying  a  stream  A  to  a  stream  B 
has  no  affect  on  the  amount  of  data  that  can  he  written  directly  to  stream  B.  A  shared 
buffer  is  only  relea.sed  after  every  leierence  to  it  in  any  stream. lias  been  deleted.  Thus, 
write  operation.s  to  .stream  A  which  has  been  copi.cd  to  stroaiT^  B  may  be  blocked  until 
data  i.s  read  from  both  .streams  A  and  .stream  B, 
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6.  CHANGES  'I'O  'I'HH  ORIGINAL  D1-:SIGN 

Few  changes  were  made  to  the  ITC!'  specifications  during  the  implementation. 
However,  one  significant  change  was  a  redistribution  of  the  functionality  provided  by 
the  packages  Stream_10  and  Stream_Services.  During  the  implementation  it  was 
realized  that  the  underlying  stream  .services  (which  were  in)t  detailed  in  the 
specification)  could  be  useful  outside  the  context  of  riXT  connection  centers.  Thus, 
interfaces  originally  intended  to  be  hidden  in  the  implementation  of  Stream_.Services 
were  instead  made  a  visible  part  of  package  Stream_IO.  Thus,  package  Streain_10 
now  provides  full  access  to  low-level  stream  functionality.  Package  Stream_Services 
was  eliminated. 

Higher-level  functionality,  a.ssociated  specifically  with  the  u.se  of  a  connection  center, 
was  removed  from  package  Stream_IO  and  placed  in  package  (’onnection  which 
already  included  interfaces  through  which  client  processes  communicate  with  a 
connection  center.  (One  regret  here  is  the  package  name  Gonnection  which  would 
more  appropriately  be  (■enter_IO.  This  could  be  fixed  in  a  future  version.)  The 
rearrangement  of  the.se  services  improves  ITCF  modularity  since  general-purpo.se 
stream  services  (provided  by  Stream_l())  can  now  be  u.sed  without  the  overhead  t)f  al.so 
binding-in  connection  center  support. 


.1 
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7.  DLMONSTRAI’ION  OF  Till-:  ITCF 

'I'he  sclcclion  of  a  dcmon.slralion  for  the  ITCF  was  a  compromise  hetween  the  desire  to 
demonslrale  a  meaningful,  non-lrivial  IT(T  application  and  the  need  to  devote  most  of 
the  available  time  to  the  implementation  of  the  ITCl'.  A  meaningful  demonstration 
would  be  one  in  which  the  functionality  of  the  existing  tools  is  integrated.  The 
repository  containing  STARS  and  SIMTFL  tools  was  considered  as  the  primary  source 
of  existing  tools.  In  order  to  minimize  the  risk  of  demonstration  problems,  attention 
was  focused  on  relatively  simple,  small  tools.  A  demonstration  of  the  ability  U) 
integrate  tools  was  of  more  interest  than  the  tools  themselves.  1‘or  example,  integratii)n 
of  the  ITCF  with  ACE  (Ada  Command  Environment)  was  considered  but  was  not 
!  undertaken,  primarily  because  ACE  is  large  body  of  software  w'hich  would  have  had  to 
be  ported  from  a  UNIX  environment  to  CAIS-A  on  a  VAX.  Al.so,  the  integration  of 
ITCI'  with  ACE  would  not  in  itself  demonstrate  the  utility  of  the  ITCF.  At  least  two 
more  tools  would  be  required  to  perform  some  sort  of  demonstration. 

7.1  Tool  Selection 

'I'here  were  several  tools  in  the  repo.sitory  which  could  perform  operations  on  Ada 
stturce  code.  These  included  editors,  spelling  checkers,  Ada  statement  counters  and 
Ada  source  code  reformatters.  Since  programn^er's  spend  much  of  the-if  tape  using 
text  editors,  it  seemed  that  a  natural  choice  for  a  demonstration  wt)uld  f)e  one  which 
extended  the  functionality  of  a  text  editor  through  integration  with  other  text  pro.essing 
tools.  'I’hus,  a  demonstration  was  conceived  in  which  an  ediU)r  would  be  the  primary 
tool  interfacing  with  the  user  and  would  be  integrated  with  other  text  processing  tools 
operating  as  servers  through  a  connection  center.  This  scenario  seemed  to  provide  a 
relatively  straight-forward  demonstration. 

A  simple  line  ediU)r,  written  in  Ada,  was  chosen  from  the  repo.siU)ry.  Although  it  is 
unlikely  that  this  particular  editor  would  be  a  heavily  used  tool  in  an  actual  SF.E,  the 
same  types  of  extensions  could  be  made  to  the  more  popular  varieties  of  screen  editors. 
For  purposes  of  the  demonstration,  addilii  .  .1  commands  were  added  to  the  editor 
which  would  be  carried  out  through  a  conncv^tion  center.  In  particular,  new  commands 
to  reformat  and  to  count  statements  in  Ada  source  code  being  edited  were  added.  These 
new  comm.inds  cause  the  contents  t)f  the  current  editor  buffer  to  be  transmitted  to  other 
'  tools  via  a  connection  center  and  a  reply  to  be  received  by  the  editor. 

An  Ada  .source  code  reformatter  was  .selected  frt)m  the  repository.  There  were  at  least 
two  choices.  The  simpler  and  smaller  reformalter  was  cho.sen.  Initially,  a  spelling 
checker  was  also  .selected  as  a  server  tool  for  the  demonstration.  However,  as  time 
began  to  run  out  it  was  decided  to  replace  the  spelling  checker  with  a  simpler  tool,  an 
Ada  statement  counter,  to  reduce  the  risk  of  not  meeting  .schedules.  'Hie  main  reasons 
for  the  .substitution  was  th<it  the  spelling  checking  had  a  very  long  startup  time  and  its 
u.ser  interface  seemed  complex.  It  was  not  clear  how  much  effort  would  be  required  to 
adapt  it  for  an  acceptable  demonstration. 
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In  Drdcr  to  clcmonslralc  the  broadcast  and  reply  con'catenalion  capabilities  of  the 
ITCr,  another  simple  command  was  added  to  the  line  editor.  'I’his  command  cau.ses  a 
message  to  be  sent  to  all  clients  of  a  connection  center  which  have  registered 
themselves  as  server  tools.  Each  tool  responds  with  its  registered  name.  The.se 
re.sponses  are  concatenated  into  a  single  stream  by  the  connection  center  and  delivered 
back  to  the  editor  which  prints  the  response.  Hence,  the  net  affect  of  the  this  new 
editor  command  is  to  poll  for  the  names  of  all  available  server  tools  which  are 
connected  to  the  center. 

7.2  'fool  Adaptation 

j  Adaptation  of  the  tools  chosen  for  integration  via  the  riXT'  was  straight-forward.  In 
the  case  i)f  the  line  editor,  the  new  commands  were  readily  added.  However,  the 
command  for  reformatting  suggested  that  another  editor  extension  would  be  necessary. 
The  problem  is  that  if  there  are  mistakes  in  the  source  code,  the  results  of  reformatting 
could  be  erroneous  in  which  ca.se  the  user  may  wish  to  restore  the  prior  contents  of  the 
editor  buffer  in  place  of  the  reformatted  contents.  The  mechanism  used  by  the  editor 
to  .store  the  text  being  edited  was  easily  modified  U)  handle  two  text  buffers  instead  of 
one.  Another  command  was  added  to  the  editor  which  allows  the  user  to  toggle 
between  these  buffers.  Thus,  after  a  buffer  is  formatted  the  user  has  the  option  of 


Both  the  reformatter  and  the  Ada  .statement  counter  tools  were  easily  adapted  since 
they  already  used  TEXT_IO  for  purposes  of  input  and  output.  Adaptation  of  these 
tools  was  largely  a  matter  of  adding  a  few  calls  to  the  JT(d’  package  Connection. 
Each  tool  had  to  perform  the  following  initialization  steps: 

•  f 

1.  Call  ()pen_Connection  to  initialize  the  connection  to  the  connection  center. 

2.  Call  Regi.sler_Pattern  U)  register  the  identification  of  the  tool  with  the  connection 
center. 

3.  Call  Activate_(a)nnection  to  notify  the  connection  center  that  the  tool  was  ready 
to  receive  request  streams. 

'^Thereafter,  the  tools  would  call  the  Receive  interface  in  package  Connection  to  receive 
each  stream  containing  source  code  to  be  prt)ce.s.sed.  The  U)ols  would  then  open  each 
stream  using  TEXT_S'rRl{AM_I().  .Since  the.se  U)ols  already  u.sed  TEX’ILK)  to  read 
their  input  and  write  their  output,  the  'I’l'X'lLlO  calls  had  only  to  be  changed  to  call 
•  TE.XT_.STR1-;A!VLI()  instead. 

More  detailed  inb)rmation  about  the  changes  made  to  loi)ls  for  <id,ipiation  can  be  found 
in  the  Ada  source  code  files  for  the  tools 
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7.3  Tool  Adaptation  Problcm.s 

Although  the  changes  necessary  U)  integrate  the  tools  with  the  ITCF  were  minor,  other 
aspects  of  tool  behavior  became  important  in  the  context  of  integration.  This  was 
particularly  evident  in  the  rel'ormatter  tool.  'I'he  rcTormatter,  as  it  was  written,  would 
stop  processing  if  it  encountered  anything  which  is  not  correct  Ada  in  its  input  stream. 
While  this  sort  of  behavior  may  be  acceptable  in  a  stand  alone  tool,  in  an  integration 
setting  it  seemed  counter-productive.  If  the  user  sent  his  editor  buffer  to  the 
reformatter,  only  part  would  come  back  in  the  (very  likely)  event  that  the  source  ca)de 
contained  errors.  Hence,  changes  were  made  to  the  reformatter  to  cause  it  to  pass 
remaining  source  code  through  unchanged  in  the  event  of  a  syntactic  error  from  which 
:  it  could  not  recover. 

'I'he  reuse  of  tools  such  as  the  reformatter  in  this  way  increases  the  need  for  tool 
reliability.  While  occasional  failures  of  a  stand-alone  tool  may  be  tolerable,  the 
failure  of  a  tool  in  a  closely  integrated  scenario  may  not  be  so  well  tolerated.  Tor 
example,  an  obvii)us  and  implied  extension  of  the  demonstration  scenario  would  be  the 
multiplexed  use  of  the  ciinnection  center  and  the  server  tools  (the  reformatter  and  the 
statement  counter)  by  .several  independent  invt)cations  of  the  editor  tool.  'I'liat  is,  the 
serviees  provided  by  the  connection  center  could  be  provided  to  multiple  independent 
users.  In  this  case,  if  one  user  sends  an  source  program  to  the  refocmatlyr  which 
causes  it  to  abort,  then  the  facility  is  also  lost  to  the  other’  users  of  tl^e  connection 
center. 

Hence,  the  robustness  of  tools  becomes  more  critical.  It  may  be  that  future 
adaptations  of  tools  to  the  ITCT  should  include  ct)nsiderations  s.uch  as  restarting  a  tool 
if  it  fails.  At  the  very  least,  when  one  tool  fails,  other  tools  connected  to  connection 
center  should  not  necessarily  fail  as  a  con.setjuence. 

7.4  Tool  Adaptation  Effort 

Much  of  the  effort  that  was  necessary  to  adapt  the  reformatter  was  spent  in  trying  to 
fix  existing  weaknes.ses  and  mcike  it  more  robust.  There  are  still  existing  bugs  in  this 
tool  which  could  not  be  fully  investigated  in  the  time  available.  Approximately  a  two 
man-weeks  of  effort  were  applied  to  this  tool. 

Adaptation  of  the  Ada  statement  counter  was  trivial,  requiring  only  a  few  hours.  It 
was  only  necessary  to  add  a  main  proce.ssing  loop. 

Adaptation  of  the  line  editor  was  fairly  straight-forward.  Some  knowledge  of  iis 
internal  structure  was  nece.ssary  in  order  to  add  the  new  commands  and  to  add  the 
capability  of  multiple  buffers  which  could  be  swapped  via  a  command.  The  editor 
adaptations  required  approximately  a  man-week. 
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Ni)lc  Ihcil  all  adaplalions  were  performed  by  a  programmer  familiar  with  the  ri'C'!' 
interface.''  but  completely  unfamiliar  with  the  tooKs  being  integrated.  No  con.sultation 
from  other.s  wa^  .sought  in  performing  the  adaptations.  Realistically,  this  situation  (no 
consultation)  probably  reflects  typical  future  tool  adaptation  .scenarios.  However, 
those  with  experti.se  in  the.se  tools  could  have  performed  the  nece.ssary  adaptations 
more  quickly. 

7.5  Instantiation  of  the  l)emon.stration  Connection  Center 


I'or  flexibility,  ITCl'  connection  center  software  is  provided  in  the  form  of  generic 
packages  which  must  be  in.stantiated  by  the  user  to  create  a  connection  center  having 
:the  desired  distribution  strategy.  The  connection  center  instantiations  used  in  the 
demonstration  are  in  a  package  called  Integration_Center.  'I’he  actual  parameters  for 
the  in.'tantiation  include  an  Ada  type  defining  patterns  and  a  matching  function  which 
compares  streams  to  he  distributed  against  patterns.  The  lntegration_Center  package 
defines  patterns  to  be  simple  .strings  up  to  20  characters  long,  'rhese  strings  are  the 
names  t)f  the  .server  iot)ls  ct)nnected  to  the  Integration_Cenler,  e.g.  "formatter"  and 
"Ada  Count".  Requests  .sent  by  the  line  editor  to  the  connech\)n  center  have  a  header 
w'hich  indicates  which  tool  is  to  receive  the  stream.  A  stream  with  the  header  is 
.sent  to  all  of  the  .server  tools  connected.  The  header  is  used  to  implement  the  editor 
command  which  polls  the  server  tools  connected  tq.,tho  connection  center,  .j, 

The  implementation  of  the  Integration_Center  was  relatively  simple  since  most  of  the 
work  is  already  taken  care  of  in  the  of  bodies  of  the  generic  packages.  However, 
instantiation  of  package  Distribution  is  non-trivial,  requiring  a  detailed  understanding 
of  how  to  distribute  call  streams  and  how  to  concatenate  thejr  corresponding  reply 
Streams,  d'he  proce.ss  of  making  a  connection  center  could  be  made  substantially  easier 
by  providing  a  higher-level  generic  package  which  would  automatically  instantiate  the 
package  Distribution  w'ith  a  standard  distribution  strategy. 

7.6  Demonstration  Performance  Results 


Responsivene.ss  of  the  special  editor  commands  was  found  to  be  fairly  good  once  all 
tools  and  the  connection  center  were  established  and  initialized.  'Pypical  response  times 
for  small  editor  buffers  is  one  or  two  seconds.  However,  the  initial  establishment  of  the 
■‘ct)nneclion  center  and  the  tool.s  is  fairly  lengthy  primarily  due  to  the  many  node 
creation  operations  performed  by  the  ('AiS-A  implementation  in  creating  the 
proce.s.ses  and  10  channels  (six  nodes  are  created  for  the  demonstration  configuralionf 
It  is  expected  that  these  creation  limes  will  be  much  shorter  in  future,  improved 
’■  releases  of  the  C'AI.S-A  implementation. 


Performance  was  significantly  poorer  when  large  streams  were  transmitted.  three 
page  source  file  can  lake  on  the  order  of  20  seconds  to  be  reformalled.  The 
comput.ilion.d  overhead  for  stream  management  is  relatively  low.  The  appatent  e.iuse 
of  the  perl\)rmance  problem  with  large  streams  is  the  u.se  of  pt)IIing  in  the  k)w  -level  lO 
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mechanism.  ll  is  likely  lhal  performance  would  be'’ much  better  if  this  polling 
mechanism  were  replaced  with  an  interrupt-driven  10  mechanism. 

7.7  Running  the  Demonstration 

The  following  steps  may  be  used  to  run  the  demonstration  on  the  Boeing  MDSC  VAX: 

1.  Logon  as  user  SOri'HC!!!!,  password  GRHLNR. 

2.  Type:  RUN  UOB.I:CAIS_LOGON  to  logon  to  the  (!AI.S.  Specify  u.ser 
rrClTDl-MO.  password  rrCMDllMO. 

3.  Wait  for  the  prompt  "file?".  'I'his  may  take  a  minute. 

4.  'I'ype  the  name  of  a  VMS  file  to  read  into  the  buffer; 
or, 

5.  Type  a  carriage  return  to  start  an  empty  buffer. 

6.  Type  "M"  (help)  and  "S"  (summary)  for  an  .editor  command  sumirictry. 

7.  Type  "A"  (append)  to  enter  an  Ada  program  from  the  keyboard.  'I’ype  (.  R 
to  end  input  mode. 

(S.  'I’ype  "L"  (list)  "A"  (all)  to  list  the  editor  buffer  contents. . 

9.  I'ype  "C"  (center)  to  poll  the  tools  connected  U)  the  ri'C’F  connection  center. 
The  names  of  the  tools  will  be  printed. 

10.  I'ype  "7,"  to  send  the  editor  buffer  to  the  Formatter  U)ol.  A  new  buffer  will  be 
returned. 

1 1 .  Type  ■  B"  Mviffer  switch)  to  toggle  back  to  the  unformatted  buffer. 

12.  Type  "K"  to  st..-.^.  the  editor  buffer  to  the  Ada  statement  counter.  The  number  of 
Ada  statements,  blank  lines,  comment  lines  etc.  will  be  printed. 

I.”'.  If  ( ■(  )NTR()1 Y  must  be  typed,  refresh  the  databa.se  before  logging  into  the 
('Al.'^'  again,  as  follows: 

Type  CONTROl.-Y 
Type  .STOP 
Type  ©RLl’RLSll 
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8.  unimpli-:mi-:nti-:i)  i-i-:aturi-:s 

Not  all  fcaturo.s  dI"  the  FIX  T  were  im  piemen  led  under  this  task.  Only  the  core  facilities 
required  for  the  demonstration  were  fully  implemented.  In  particular,  the  following 
rrC.'l'  packa*  e  ■Te  not  implemented: 

Pac'-v.  .Stream_lO  -  protocol  for  transmitting  Ada  data  structures  in  a 

»  .'C*  '''I  'I*  y  lorm. 


Packagt  SequentialjStream_IO  -  an  ITC’P  version  of  Ada's  SequentiaLlO. 

Packa**-  ‘■'3'‘ssage_IO  -  a  generic  package  for  the  convenient  encoding  and 
decodii.  el  short  streams. 

Also,  the  capability  to  connect  together  several  connection  centers  was  not 
irnpleni.  iited.  'I'his  feature  is  u.seful  primarily  in  the  implemenlaJon  conneclit)ns 
between  different  hi)sts.  e.g.  to  .suppi)rl  remote  p.  ocedure  calls  among  a  network  of 
loosely  coupled  hosts. 


.1 
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9.  CONCLUSIONS  AND  I.LISSONS  LLARNLD 

This  successful  implemcnlalion  anti  tlcmonslralion  of  the  rrCF  proves  ihal  the  ITCF 
concept  is  workable  and  that  il  has  practical  applicativ)ns.  Although  the  demonstration 
tools  (especially  the  line  editor)  may  not  bo  heavily  used  in  a  real  SFF..  the  same 
principles  applied  to  adapt  these  tools  could  be  applied  to  more  popular  screen  editors 
and  more  sophisticated  source  reformatters  and  other  source  analysis  tools. 


'I'he  extension  ot  a  tool  (such  as  an  edito*)  through  exploitation  of  the  functionality  of 
other  tools  certainly  appears  worth  pursuing.  Such  extensions  v)f  functionality  through 
in  ogration  of  independent  tools  has  several  advantages.  In  the  sample  demonstration.. 
:tool  functionality  is  made  more  ..ccessible  to  the  user.  Without  the  use  of  1T(T’ 
integration,  the  u.ser  wishing  to  leformat  his  source  program  (under  development)  is 
fo.'‘ced  to  exit  the  editor,  type  a  iwiigthy  command  to  invoke  the  reformatter  specifying 
the  Kicalion  of  the  program  to  be  reformatted  and  the  li)cation  for  the  resulting  output 
(which  may  be  .sub.setiuently  di.scarded).  'I'he  user  must  examine  the  results  and  then 
re-invoke  the  editor  to  ctinlinue  development  of  the  .source  program.  .Such  obstacles  to 
tool  Usage  (in  this  case  the  use  of  the  reformatter)  are  likely  to  leave  such  tools 
underutilized  or  even  unutilized.  On  the  other  hand,  with  integration  through  the  ITCF, 
the  reformatting  function  becomes  immediately  available  without  exiting  the  editor. 
Only  a  simple  command  need  be  typed;  the  .source  is  rei’ormatted  aiKj.  iminediateiy 
available  for  further  inspection  and  editing.  ^ 


Similarly,  a  user  of  the  editor  may  wish  to  know  if  he  has  exceeded  the  source  code 
de  opment  guidelines  of  his  project  (which  require  that  Ada  procedures  contain  less 
tha  1  50  statements)  as  he  is  actually  typing  the  procedure.  If. the  user  must  exit  tlv' 
editor  .se.ssion  in  order  to  use  the  Ada  '..itement  co.u.nlcr  tool,  then  the  statement 
counter  tool  will  be  much  le.ss  useful  to  him. 


In  addition  to  the  user  convenience  which  ri’CF  integra*' "?  may  provide,  there  are 
other  advantages.  Tools  w'hich  are  integrated  through  the  •  • I  “ still  independent  of 
one  another.  They  can  be  linked  and  maintained  indej^  ”idently  of  one  another. 
Separately  linked  tools  integrated  through  ITC’F  occupy  le.ss  memory  than  would  be 
required  if  the  tools  were  integrating  by  linking  them  into  common  memory  images. 
Moreover,  due  to  miming  conflicts  in  independently  developed  tools,  such  linking  is  not 


'  ai  vitys  possible. 


When  a  shared  connection  center  with  .server  tools  is  used  by  .several  users,  each  .server 
tool  is  repre.senied  as  a  single,  serially  reusable  proce.ss.  'I'liis  has  .several  advantages. 
The  tool  images  (even  if  non-reentrant)  are  repi*. '.seated  only  once  in  memor_ .  The 
number  of  prote.s.ses  which  must  be  managed  by  the  underlying  system  is  smaller.  The 
tool  images  are  not  reloaded  from  disk  each  time  they  are  invoked.  'I'he  tool 
elaboration  .iiul  <)iher  tool  initialization  is  performed  only  once  for  all  users. 
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A  typical  problem  in  shared  processing  cnvironm'enis  i.s  the  use  of  large, 
resource- intensive  tools  (such  as  an  Ada  compiler)  by  .several  users  concurrently. 
Sometimes  as  lew  as  two  concurrent  invocations  of  such  tools  can  drastically  reduce 
.system  through-put  due  to  contention  for  memory,  pnjces.sing.  and  10  resources.  'I'he 
rrer  can  be  Used  (as  demonstrated)  to  conveniently  .serialize  acce.ss  to_  such  tools  in 
order  to  maximize  through-put  in  these  types  of  environments.  I'or  example,  a 
common  connection  center  could  used  by  all  ('1,1  proce.s.ses  to  .serialize  the  use  of  the 
compiler  and  other  tools 
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10.  FUTURE  APPLlCA'l'lONS 


The  connection  center  and  other  concepts  employed  in  the  IT(T'  are  relatively  new. 
'I'he  potential  applications  are  as  yet  not  fully  defined.  'I'he  design  and  implementation 
of  the  ITCF  have  been  done  with  flexibility  uppermost  in  order  that  the  potential  i)f 
this  tool  not  be  limited  to  specific  integration  scenarios  that  happened  to  be  envisioned 
by  the  ITCF  designers  and  implementers. 

Other  practical  application  scenarios  should  be  investigated  as  the  SPARS  program 
continues.  'Phere  may  be  man)  as  yet  uninvestigated  applications.  One  path  toward 
wider  application  would  be  to  make  the  PIX!!’*  facilities  more  readily  available  at  the 
•  Command  Line  Interpreter  level  of  the  environment.  This  could  be  accompli.shed  by 
implementing  the  PPC"!'  mechanisms  which  support  RPC'  (remote  procedure  call)  and 
then  integrating  the  PPC'F  functionality  into  AC!E  (the  Ada  C'ommand  Environment). 


Another  area  for  application  of  the  PPCF  could  be  application  program  development 
and  testing.  The  use  of  software-first  methodologies  will  lead  to  the  need  to  test 
application  software  within  the  software  development  environment  before  the  target 
hardware  is  available.  Many  applications  to  be  developed  are  real-time  systems 
utilizing  tasks  that  respond  to  incoming  "sU  earns"  of  environmental  data.  'Phere  is 


clearly  potential  here  to  use  the  PPCF  to  create  simulated  eiivironments  and  to.  monitor 
and  record  responses.  3'here  is  even  the  possibility  of  direct  use  of  PPCE  stretim 


management  facilities  in  the  applications  them.selves  as  a  means  of  efficient  inter 


communication  and  transient  data  management. 
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1 .  Introduction 

The  Inter-Tool  Coiranunication  Facility  (ITCF)  was  specified  under .STARS  Task 
Qll.  A  VAX/CAIS-A  implementation  of  the  core  ITCF  facilities,  a 
demonstration  of  the  ITCF  using  existing  tools,  and  this  final  report  were 
completed  under  STARS  Task  BR67.  This  reports  describes  the  ITCF,  the 
design,  the  implementation,  and  the  demonstration  performed.  More  detailed 
documentation  and  information  about  the  ITCF  and  the  demonstration  tools 
can  be  found  in  the  ITCF  Version  Description  and  in  the  source  code  for  the 
ITCF  packages  and  for  demonstration  tools.  All  ITCF  deliverables  including 
source  code  and  reports  are  currently  on  the  MDSC  VAX  under  the  root 
directory : 

SyS$USER7 [SOFTECHl . USERS . SABBUHL. ITCF] 

The  file: 

SYS$USER7 [ SOFTECHl . USERS . SABBUHL . ITCF] ITCF_VERSION_DESCRIPTION . ADS 
describes  the  directory  organization  of  the  deliverables. 


2.  General  Description 

The  following  is  a  general  description  of  the  ITCF.  More  details  can  be 
found  in  the  file  ITCF_Version_Description . ads  and  in  the  package 
specifications  and  bodies  for  the  delivered  software. 

The  ITCF  permits  concurrently  executing  tools  to  cooperate  in  an  integrated 
manner  while  maintaining  their  high  degree  of  modularity  and  functional 
independence.  The  ITCF  offers  a  layered  architecture  of  communication 
services  which  may  be  adapted  to  meet  the  requirements  of  a  variety  of  tool 
integration  strategies.  The  principle  conceptual  layers  are  streams,  stream 
protocols  and  messages. 

The  ITCF  services  manage  the  complex  details  of  inter-tool  communication 
and  provide  conceptually  simple  and  easy  to  use  interfaces  to  the  tool 
writer.  These  services  facilitate  the  integration  of  tools  with  relatively 
modest  effort,  including  existing  tools  which  were  not  originally  designed 
to  use  the  ITCF  packages. 

The  ITCF  is  intended  to  transfer  data  which  is  primarily  transient  in 
nature  as  opposed  to  data  which  is  permanently  stored  in  the  environment 
data  base.  Permanent  data  should  be  handled  through  the  environment  object 
management  system.  Nevertheless,  simple  tools  can  be  implemented,  using 
the  ITCF  packages,  which  allow  the  connection  of  other  tools  to  files 
(including  devices)  as  sources  and  sinks  for _ inter-tool  data. 

The  ITCF  is  also  intended  to  support  communication  between  tools  executing 
in  different  CAIS-A  environments  that  are  connected  by  a  gateway.  However, 
this  feature  was  not  implemented  under  task  BR67. 


3 .  ITCF  Concepts 

The  underlying  concepts  of  the  ITCF  have  been  derived  from  a  number  of 
sources.  These  include  UNIX  pipes,  plumbing  fixtures  and  filters;  the 
CAIS-A  10  Connection  Model;  and  various  Remote  Procedure  Call  (RPC) 


facilities  and  stream  manipulation  packages.  The  FIELD  environment 
integration  mechanism,  described  by  Steven  Reiss  of  Brown  University,  was 
particularly  influential . 


3.1  Clients  and  Connection  Centers 

The  focus  of  ITCF  operations  are  server  processes  called  connection 
centers.  A  given  connection  center  may  have  one  or  more  clients.  A  client 
may  be  a  tool  ( i . e .  a  process ) ,  or  a  gateway .  A  gateway  client  represents 
other  clients  and/or  connection  centers  on  a  remote  host  system.  Clients 
communicate  with  one  another  via  the  connection  center. 

The  first  step  in  using  the  ITCF  is  the  creation  of  a  connection  center. 
After  the  center  has  been  created,  clients  may  be  connected  to  the  center. 
Connection  of  a  client  to  a  connection  center  establishes  a  communications 
channel  between  the  client  and  the  center.  This  channel  is  called  a 
connection.  Clients  may  be  connected  or  disconnected  at  any  time.  Only 
clients  of  the  same  center  may  communicate  with  one  another.  Each  client  ■ 
may  be  connected  to  only  one  center  at  a  given  time.  Clients  may 
communicate  through  the  connection  center  concurrently. 


3 . 2  Streams 

At  the  lowest  conceptual  layer  of  the  ITCF,  data  is  passed  through  the 
connection  center  in  the  form  of  streams.  A  stream  is  simply  a  sequence  of 
data  (of  indefinite  length)  generated  by  a  client.  A  client  sends  data  by 
writing  into  a  stream.  A  client  receives  data  by  reading  from  a  stream. 

The  flow  of  data  in  a  stream  is  uni-directional.  When  bi-directional  flow 
is  required,  a  reverse  stream  called  a  reply  stream  may  be  used.  A  client 
process  may  use  multiple  streams  concurrently.  The  flow  of  data  in  each 
stream  is  independent  of  other  unrelated  streams. 

Streams  may  be  used  by  processes  for  direct  communication  without  the  use 
of  a  connection  center.  Connection  center  facilities  are  built  on  top  of 
the  lower-level  stream  services.  Streams  may  also  be  used  locally  within  a 
process  for  communication  between  tasks  without  the  overhead  associated 
with  sending  streams  through  a  separate  connection  center  process. 


4 .  Implementation  Overview 


The  core  facilities  of  the  ITCF  were  implemented  on  the  MDSC  VAX  machine 
using  VAXAda  2.0  and  Version  4.5  of  the  CAIS-A  implementation.  The  ITCF 
services  are  provided  as  a  collection  of  packages  containing  interfaces 
which  may  be  called  by  CAIS  tools. 


The  principal  packages  implemented  are: 


Stream_I0 

Text_Stream_IO 

Connection 

Connection_Center 

Distribution 


Supports  all  lov7-level  stream  operations 
including  interprocess  communication. 

Provides  the  interfaces  of  Ada  Text_IO  for 
reading  and  v/riting  stream  data. 

Provides  interfaces  that  client  tools  call  to 
interface  with  a  connection  center. 

A  generic  package  which  supports  the 
instantiation  of  user  defined  connection 
centers . 

A  generic  package  v;hich  performs  general 
distribution  list  management  functions  for 


instantiations  of  package  ConnectionjCenter . 

Monitor  -  A  low-level  packages  which  is  used  to  manage 

concurrent  access  to  streams.  This  is  an 
internal  ITCF  package  which  contains  no  tool 
interfaces. 


5.  Design  Problems  and  Solutions 

Aspects  of  the  ITCF  implementation  which  presented  significant  technical 
challenges  were  the  management  of  concurrent  access  to  streams  and  the 
interprocess  connection  resources,  and  the  mechanism  to  support  stream 
copying.  Stream  copying  is  a  fundamental  ITCF  concept  of  substantial  power 
in  affecting  the  distribution  of  streams  and  the  composition  of  streams 
from  other  streams. 


5.1  Concurrent  Access  to  Streams 

Two  problems  needed  to  be  addressed  in  the  handling  of  concurrent  access. 
The  first  was  to  develop  a  conceptual  model  that  would  make  a  correct 
implementation  conceptually  manageable.  The  second  problem  was  to  assure 
that  management  of  concurrent  access  v7ould  be  reasonably  efficient. 


5.1.1  Using  Ada  Rendezvous 

Initial  attempts  to  achieve  a  conceptual  model  for  concurrent  access  were 
focused  on  the  direct  use  of  the  Ada  rendezvous  model.  One  question  was 
how  tasking  should  be  applied.  The  Ada  rendezvous  model  is  generally 
applied  by  identifying  a  object  to  which  concurrent  access  may  occur  and 
then  applying  a  task  to  manage  the  object.  All  access  to  the  object  is 
then  accomplished  through  calling  entries  to  that  task.  Hence,  one  attempt 
to  the  solve  concurrent  access  problems  in  the  ITCF  was  to  have  each  stream 
be  managed  by  a  separate  task.  This  approach  was  eventually  rejected 
because  it  v;ould  require  a  large  number  of  tasks,  straining  system 
resources.  Also,  it  was  not  clear  how  stream  copying  could  be  implemented. 
Stream  copying  v;ould  either  require  1)  stream-tasks  to  call  other 
stream-tasks,  thereby  making,  themselves  unavailable  for  satisfying  other 
concurrent  access  to  the  stream,  or  2)  the  creation  of  addition  copy- tasks 
that  V70uld  simply  read  data  from  one  stream- task  and  write-data  to  another. 

VJhile  such  tasks  could  be  recycled,  thus  reducing  the  overall  overhead  of 
frequent  task  creation,  the  number  of  tasks  that  would  be  required  was 
still  of  some  concern. 

Another  approach  to  using  rendezvous  was  to  define  a  single  task  which 
provides  all  services  to  all  streams.  This  task  would  serialize  access  to 
all  stream  operations.  Vihile  this  approach  would  greatly  reduce  the  number 
of  tasks  required,  it  had  some  disadvantages.  One  disadvantage  was  that 
all  stream  functions  would  have  to  be  provided  in  a  single  large  task  body. 
In  order  to  modularize  these  functions,  calls  would  have  to  be  used  in  the 
ACCEPT  statements  of  this  task  body  adding  additional  overhead  (which  could 
possibly  be  reduced  through  the  use  of  PRAGMA  I^^LIKB) .  Also,  how  to 
interface  with  other  tasks  which  manage  transmission  of  streams  over 
connections  V7as  not  clear. 

vThile  these  problems  probably  could  be  overcome,  there  was  one  problem  that 
was  shared  by  all  approaches  that  used  .Ada  rendezvous  exclusively:  every 
operation  on  a  stream  would  involve  four  tasks  switches.  Task  switching 
has  certain  unavoidable  overhead  even  in  the  best  Ada  runtin-x? 
implementations.  All  registers  must  be  stored  and  loaded,  and  the 
scheduling  algorithm  must  be  invoked.  This  would  imr*ly  that  an  operation 
which  is  to  'write  a  single  byte  to  a  stream  could  have  art  overhead  on  the 
order  of  a  hundred  instructions.  This  overhead  could  be  significantly 
reduced  by  usir»q  buffering  tc,  minimise  th‘=*  riurl*f-i  -tf  rendezvous  reqttirel  fe* 


transmit  a  given  amount  of  data.  However,  this  would  only  help  in  the  Put 
and  Get  functions  in  package  Stream_IO.  The  overhead  for  all  other 
functions  would  not  be  reduced. 


5.1.2  Using  Monitors 

An  alternative  approach  was  to  apply  Hoare's  Monitor  concept.  In  this 
approach,  the  set  of  all  streams  is  considered  a  shared  resource  to  which 
access  is  control  via  a  monitor  entity.  Whenever  a  task  needs  to  operate 
on  a  stream,  it  must  first  enter  the  monitor.  Monitor  entry  is  queued  so 
that  only  one  task  can  execute  within  the  monitor  at  a  time.  If  the 
operation  cannot  be  completed  immediately  (for  example  an  attempt  to  read  a 
stream  which  is  temporarily  empty),  the  task  may  suspend  itself  on  a 
condition  variable  until  the  operation  can  be  completed.  \'fhen  a  task 
suspends  itself  within  a  monitor,  another  task  is  allowed  to  enter. 
Eventually,  a  task  will  enter  which  writes  to  the  stream  and  signals  the 
condition  variable  upon  which  the  suspended  task  is  waiting. 


5.1.3  Monitor  Implementation 

The  monitor  framework  was  very  helpful  in  sorting  out  the  concurrent  access 
problems.  However,  since  Ada  does  not  directly  support  monitors,  it  was 
necessary  to  consider  how  they  would  be  implemented.  Waiting  must  occur 
when  a  task  attempts  to  enter  a  monitor,  if  another  task  is  using  the 
monitor,  and  when  a  task  must  be  suspended  on  a  condition  variable.  In  Ada, 
the  only  way  for  a  task  to  wait  until  some  event  occurs  is  through  a  call 
to  a  task  entry.  A  very  simple  and  direct  approach  to  the  monitor  entry 
problem  is  to  use  a  simple  task  which  alternately  accepts  an  entry  call  to 
enter  the  monitor  and  an  entry  call  to  leave  the  monitor.  The  major 
drawback  to  this  solution  is  that  the  cycle  of  entering  and  leaving  the 
monitor  would  require  two  rendezvous  involving  eight  task  switches. 

However,  an  important  observation  is  that,  in  most  cases,  when  a  task 
attempts  to  enter  the  monitor  there  will  be  no  task  executing  in  the 
monitor.  Thus,  in  most  cases  a  rendezvous  should  be  unnecessary.  In  the 
ITCF  implementation,  a  counter  which  can  be  incremented/decremented  and 
tested  as  an  atomic  operation  is  used  to  determine  whether  a  task  is 
currently  executing  within  the  monitor.  A  rendezvous  is  used  to  suspend  an 
entering  task  only  if  the  result  of  incrementing  the  counter  indicates  that 
another  task  is  already  executing  inside  the  monitor.  This  strategy 
reduces  the  overhead  of  monitor  entry  and  exit  to  a  few  instructions, 
versus  the  hundreds  of  instructions  that  would  be  executed  using  rendezvous 
exclusively . 

The  technique  used  could  be  criticized  for  not  being  pure  Ada.  However, 
the  only  implementation  dependency  introduced  by  this  technique  is  the 
implementation  of  the  atomic  counter  on  the  host.  Most  processors  have 
such  an  instruction.  Others  have  an  instruction  (such  as  a  test  and  set) 
which  can  be  used  to  synthesize  an  atomic  counter.  I.t  the  case  of  the  VAX, 
the  VAXAda  compiler  has  a  built-in  procedure  for  an  atomic  counter.  For 
other  hosts  or  compiling  systems,  it  may  be  necessary  to  write  a  small 
assembly  language  unit. 

In  any  case,  the  dependency  is  isolated  within  a  small  package  called 
Protected_Counter .  There  is  no  dependency  on  the  Ada  run-time 
implementation.  All  tasking  operations  are  still  handled  in  pure  Ada. 


5.2  Strear.  Copying 

Several  false  starts  V7ere  required  in  the  design  of  stream  copying  before  a 
satisfactory  solution  war  arrived  at.  The  final  solution  was  to  place  an 
item  representing  the  tail"  (i.e.  the  remainder)  of  a  copied  stream  in  the 
item  queue  of  every  target  stream  to  which  the  stream  is  copied.  These 


tails  are  kept  on  a  list.  Each  time  another  data  buffer  is  added  to  the 
source  stream,  an  item  referencing  that  buffer  is  inserted  into  each  target 
stream  immediately  ahead  of  each  tail  (in  the  list  of  tails)  for  the  copied 
stream.  This  effectively  copies  the  data  into  each  target  stream  at  the 
appropriate  point  within  each  of  those  streams.  When  the  copied  stream  is 
closed,  the  tails  are  discarded  since  no  further  insertions  of  data  from 
the  copied  .ream  are  necessary. 

In  applicat-.ons  involving  large  streams,  the  amount  of  data  which  is 
buffered  in  a  stream  must  be  bounded  to  prevent  storage  resources  from 
being  exhausted.  Handling  of  bounded  buffering  in  streams  was  problematic 
due  to  the  copying  facility.  Initial,  it  was  not  clear  how  to  account  for 
buffered  data  which  has  been  copied.  As  the  design  of  the  copy  capability 
progressed,  it  was  decided  that  buffers  would  be  copied  by  reference  rather 
than  by  value  for  efficiency  reasons.  The  accounting  problem  of  placing 
bounds  on  buffering  was  then  solved  by  designating  the  stream  to  which  data 
is  originally  w.ritten  as  the  owner  of  that  data.  Thus,  copying  a  stream  A 
to  a  stream  B  has  no  affect  on  the  amount  of  data  that  can  be  written 
directly  to  stream  B.  A  shared  buffer  is  only  released  after  every 
reference  to  it  in  any  stream  has  been  deleted.  Thus,  write  operations  to 
stream  A  which  has  been  copied  to  stream  B  may  be  blocked  until  data  is 
read  from  both  streams  A  and  stream  B. 


6 .  Changes  to  the  Original  Design 

Few  changes  were  made  to  the  ITCF  specifications  during  the  implementation. 
However,  one  significant  change  was  a  redistribution  of  the  functionality 
provided  by  the  packages  Stream_IO  and  Stream_Services .  During  the 
implementation  it  was  realized  that  the  underlying  stream  services  (which 
were  not  detailed  in  the  specification)  could  be  useful  outside  the  context 
of  ITCF  connection  centers.  Thus,  interfaces  originally  intended  to  be 
hidden  in  the  implementation  of  Stream_Services  were  instead  made  a  visible 
part  of  package  Stream_IO.  Thus,  package  Stream_IO  now  provides  full 
acces's  to  low-level  stream  functionality.  Package  Stream_Services  was 
eliminated . 

Higher-level  functionality,  associated  specifically  with  the  use  of  a 
connection  center,  was  removed  from  package  Stream_IO  and  placed  in  package 
Connection  which  already  included  interfaces  through  which  client  processes 
communicate  with  a  connection  center.  (One  regret  here  is  the  package  name 
Connection  which  would  more  appropriately  be  Center_IO.  This  could  be 
fixed  in  a  future  version.)  The  rearrangement  of  these  services  improves 
ITCF  modularity  since  general-purpose  stream  services  (provided  by 
Stream_IO)  can  now  be  used  without  the  overhead  of  also  binding-in 
connection  center  support. 


7 .  Demonstration  of  the  ITCF 

The  selection  of  a  demonstration  for  the  ITCF  was  a  compromise  between  the 
desire  to  demonstrate  a  meaningful,  non-trivial  ITCF  application  and  the 
need  to  devote  most  of  the  available  time  to  the  implementation  of  the 
ITCF.  A  meaningful  demonstration  would  be  one  in  which  the  functionality  of 
the  existing  tools  is  integrated.  The  repository  containing  STARS  and 
SIMTEL  tools  was  considered  as  the  primary  source  of  existing  tools.  In 
order  to  minimize  the  risk  of  demonstration  problems,  attention  was  focused 
on  relatively  simple,  small  tools.  A  demonstration  of  the  ability  to 
integrate  tools  was  of  more  interest  than  the  tools  themselves.  For 
example,  integration  of  the  ITCF  with  ACE  (Ada  Command  Environment)  was 
considered  but  was  not  undertaken,  primarily  because  ACE  is  large  body  of 
software  which  would  have  had  to  be  ported  from  a  UNIX  environment  to 
CAIS-A  on  a  VAX.  Also,  the  integration  of  ITCF  with  ACE  would  not  in 
itself  demonstrate  the  utility  of  the  ITCF.  At  least  two  more  tools  would 
be  required  to  perform  some  sort  of  demonstration. 


7 . 1  Tool  Selection 


There  were  several  tools  in  the  repository  which  could  perform  operations 
on  Ada  source  code.  These  included  editors,  spelling  checkers,  Ada 
statement  counters  and  Ada  source  code  reformatters.  Since  programmer's 
spend  much  of  their  time  using  text  editors,  it  seemed  that  a  natural 
choice  for  a  demonstration  would  be  one  which  extended  the  functional! •'  y  of 
a  text  editor  through  integration  with  other  text  processing  tools.  Tnus, 
a  demonstration  was  concei’/ed  in  which  an  editor  would  be  the  primary  tool 
interfacing  with  the  user  and  would  be  integrated  with  other  text 
processing  tools  operating  as  servers  through  a  connection  center.  This 
scenario  seemed  to  provide  a  relative3.y  straight-forward  demonstration. 

A  simple  line  editor,  written  in  Ada,  was  chosen  from  the  repository. 
Although  it  is  unlikely  that  this  particular  editor  would  be  a  heavily  used 
tool  in  an  actual  SEE,  the  same  types  of  extensions  could  be  made  to  the 
more  popular  varieties  of  screen  editors.  For  purposes  of  the 
demonstration,  additional  commands  were  added  to  the  editor  which  would  be 
carried  out  through  a  connection  center.  In  particular,  new  commands  to 
reformat  and  to  count  statements  in  Ada  source  code  being  edited  were 
added.  These  new  commands  cause  the  contents  of  the  current  editor  buffer 
to  be  transmitted  to  other  tools  via  a  connection  center  and  a  reply  to  be 
received  by  the  editor. 

An  Ada  source  code  reformatter  was  selected  from  the  repository.  There 
were  at  least  two  choices.  The  simpler  and  smaller  reformatter  was  chosen. 
Initially,  a  spelling  checker  was  also  selected  as  a  server  tool  for  the 
demonstration.  However,  as  time  began  to  run  out  it  was  decided  to  replace 
the  spelling  checker  with  a  simpler  tool,  an  Ada  statement  counter,  to 
reduce  the  risk  of  not  meeting  schedules.  The  main  reasons  for  the 
substitution  was  that  the  spelling  checking  had  a  very  long  startup  time 
and  its  user  interface  seemed  complex.  It  was  not  clear  how  much  effort 
would  be  required  to  adapt  it  for  an  acceptable  demonstration. 

In  order  to  demonstrate  the  broadcast  and  reply  concatenation  capabilities 
of  the  ITCF,  another  simple  command  was  added  to  the  line  editor.  This 
command  causes  a  message  to  be  sent  to  all  clients  of  a  connection  center 
which  have  registered  themselves  as  server  tools.  Each  tool  responds  with 
its  registered  name.  These  responses  are  concatenated  into  a  single  stream 
by  the  connection  center  and  delivered  back  to  the  editor  which  prints  the 
response.  Hence,  the  net  affect  of  the  this  new  editor  command  is  to  poll 
for  the  names  of  all  available  server  tools  which  are  connected  to  the 
center . 


7 . 2  Tool  Adaptation 

Adaptation  of  the  tools  chosen  for  integration  via  the  ITCF  was 
straight-forward.  In  the  case  of  the  line  editor,  the  new  commands  were 
readily  added.  However,  the  command  for  reformatting  suggested  that 
another  editor  extension  would  be  necessary.  The  problem  is  that  if  there 
are  mistakes  in  the  source  code,  the  results  of  reformatting  could  be 
erroneous  in  which  case  the  user  may  wish  to  restore  the  prior  contents  of 
the  editor  buffer  in  place  of  the  reformatted  contents.  The  mechanism  used 
by  the  editor  to  store  the  text  being  edited  was  easily  modified  to  handle 
two  text  buffers  instead  of  one.  Another  command  was  added  to  the  editor 
which  allows  the  user  to  toggle  between  these  buffers.  Thus,  after  a 
buffer  is  formatted  the  user  has  the  option  of  switching  back  to  the 
original  text  buffer  as  it  was  before  invoking  the  reformatter. 

Both  the  reformatter  and  the  Ada  statement  counter  tools  were  easily 
adapted  since  they  already  used  TEXT_IO  for  purposes  of  input  and  output. 
Adaptation  of  these  tools  v/as  largely  a.  matter  of  adding  a  few  calls  to  the 
ITCF  package  Connection.  Each  tool  had  to  perform  the  follov;ing 
initialization  steps: 


1.  Call  Open_Connection  to  initialize  the  connection  to  the  connection 
center . 

2.  Call  Register_Pattern  to  register  the  identification  of  the  tool 
with  the  connection  center. 

3.  Call  Activate_Connection  to  notify  the  connection  center  that  the 
tool  was  ready  to  receive  request  streams. 


Thereafter,  the  tools  would  call  the  Receive  interface  in  package 
Connection  to  receive  each  stream  containing  source  code  to  be  processed. 
The  tools  would  then  open  each  stream  using  TEXT_STREAM_IO .  Since  these 
tools  already  used  TEXT_IO  to  read  their  input  and  write  their  output,  the 
TEXT__IO  calls  had  only  to  be  changed  to  call  TEXT_STREAM_IO  instead. 

More  detailed  information  about  the  changes  made  to  tools  for  adaptation 
can  be  found  in  the  Ada  source  code  files  for  the  tools. 


7 . 3  Tool  Adaptation  Problems 

Although  the  changes  necessary  to  integrate  the  tools  with  the  ITCF  were 
minor,  other  aspects  of  tool  behavior  became  important  in  the  context  of 
integration.  This  was  particularly  evident  in  the  reformatter  tool.  The 
reformatter,  as  it  was  written,  would  stop  processing  if  it  encountered 
anything  which  is  not  correct  Ada  in  its  input  stream.  While  this  sort  of 
behavior  may  be  acceptable  in  a  stand  alone  tool,  in  an  integration  setting 
it  seemed  counter-productive.  If  the  user  sent  his  editor  buffer  to  the 
reformatter,  only  part  would  come  back  in  the  (very  likely)  event  that  the 
source  code  contained  errors.  Hence,  changes  were  made  to  the  reformatter 
to  cause  it  to  pass  remaining  source  code  through  unchanged  in  the  event  of 
a  syntactic  error  from  which  it  could  not  recover. 

The  reuse  of  tools  such  as  the  reformatter  in  this  way  increases  the  need 
for  tool  reliability.  While  occasional  failures  of  a  stand-alone  tool  may 
be  tolerable,  the  failure  of  a  tool  in  a  closely  integrated  scenario  may  not 
be  so  well  tolerated.  For  example,  an  obvious  and  implied  extension  of  the 
demonstration  scenario  would  be  the  multiplexed  use  of  the  connection  center 
and  the  server  tools  (the  reformatter  and  the  statement  counter)  by  several 
independent  invocations  of  the  editor  tool.  That  is,  the  services  provided 
by  the  connection  center  could  be  provided  to  multiple  independent  users. 

In  this  case,  if  one  user  sends  an  source  program  to  the  reformatter  which 
causes  it  to  abort,  then  the  facility  is  also  lost  to  the  other  users  of 
the  connection  center. 

Hence,  the  robustness  of  tools  becomes  more  critical.  It  may  be  that 
future  adaptations  of  tools  to  the  ITCF  should  include  considerations  such 
as  restarting  a  tool  if  it  fails.  At  the  very  least,  when  one  tool  fails, 
other  tools  connected  to  connection  center  should  not  necessarily  fail  as  a 
consequence. 


7.4  Tool  Adaptation  Effort 

Much  of  the  effort  that  was  necessary  to  adapt  the  reformatter  was  spent  in 
trying  to  fix  existing  weaknesses  and  make  it  more  robust.  There  are  still 
existing  bugs  in  this  tool  which  could  not  be  fully  investigated  in  the 
time  available.  Approximately  a  two  man-weeks  of  effort  were  applied  to 
this  tool. 

Adaptation  of  the  Ada  statement  counter  was  trivial,  requiring  only  a  few 
hours.  It  was  only  necessary  to  add  a  main  processing  loop. 

Adaptation  of  the  line  editor  was  fairly  straight-forward.  Some  knov/ledge 


of  its  internal  structure  was  necessary  in  order  to  add  the  new  commands 
and  to  add  the  capability  of  multiple  buffers  which  could  be  swapped  via  a 
command.  The  editor  adaptations  required  approximately  a  man-week. 

Note  that  all  adaptations  were  performed  by  a  programmer  familiar  with  the 
ITCF  interfaces  but  completely  unfamiliar  with  the  tools  being  integrated. 
No  consultation  from  others  was  sought  in  performing  the  adaptations. 
Realistically,  this  situation  (no  consultation)  probably  reflects  typical 
future  tool  adaptation  scenarios.  However,  those  with  expertise  in  these 
tools  could  have  performed  the  necessary  adaptations  more  quickly. 


7.5  Instantiation  of  the  Demonstration  Connection  Center 

For  flexibility,  ITCF  connection  center  software  is  provided  in  the  form  of 
generic  packages  which  must  be  instantiated  by  the  user  to  create  a 
connection  center  having  the  desired  distribution  strategy.  The  connection 
center  instantiations  used  in  the  demonstration  are  in  a  package  called 
Integration_Center .  The  actual  parameters  for  the  instantiation  include  an 
Ada  type  defining  patterns  and  a  matching  function  which  compares  streams 
to  be  distributed  against  patterns.  The  Integration_Center  package  defines 
patterns  to  be  simple  strings  up  to  20  characters  long.  These  strings  are 
the  names  of  the  server  tools  connected  to  the  Integration_Center,  e.g. 
"Formatter"  and  "Ada  Count" .  Requests  sent  by  the  line  editor  to  the 
connection  center  have  a  header  which  indicates  which  tool  is  to  receive 
the  stream.  A  stream  with  the  header  is  sent  to  all  of  the  server 
tools  connected.  The  header  is  used  to  implement  the  editor  command 
which  polls  the  server  tools  connected  to  the  connection  center. 

The  implementation  of  the  Integration_Center  was  relatively  simple  since 
most  of  the  v7ork  is  already  taken  care  of  in  the  of  bodies  of  the  generic 
packages.  However,  instantiation  of  package  Distribution  is  non-trivial, 
requiring  a  detailed  understanding  of  how  to  distribute  call  streams  and 
how  to  concatenate  their  corresponding  reply  streams.  The  process  of 
making  a  connection  center  could  be  made  substantially  easier  by  providing 
a  higher- level  generic  package  which  would  automatically  instantiate  the 
package  Distribution  with  a  standard  distribution  strategy. 


7.6  Demonstration  Performance  Results 

Responsiveness  of  the  special  editor  commands  was  found  to  be  fairly  good 
once  all  tools  and  the  connection  center  were  established  and  initialized. 
Typical  response  times  for  small  editor  buffers  is  one  or  two  seconds. 
However,  the  initial  establishment  of  the  connection  center  and  the  tools 
is  fairly  lengthy  primarily  due  to  the  many  node  creation  operations 
perform  '  by  the  CAIS-A  implementation  in  creating  the  processes  and  10 
channels  ^six  nodes  are  created  for  the  demonstration  configuration).  It 
is  expected  that  these  creation  times  will  be  much  shorter  in  future, 
improved  releases  of  the  CAIS-A  implementation. 

Performance  was  significantly  poorer  when  large  streams  were  transmitted.  A 
three  page  source  iile  can  take  on  the  order  of  20  seconds  to  be 
reformatted.  The  computational  overhead  for  stream  management  is  relatively 
low.  The  apparent  cause  of  the  performance  problem  with  large  streams  is 
the  use  of  polling  in  the  low-level  10  mechanism.  It  is  likely  that 
performance  would  be  much  better  if  this  polling  mechanism  were  replaced 
with  an  interrupt-dr  a  vi'n  10  mechanism. 


7 . 7  Running  thvj  Demonstration 

The  following  steos  may  be  used  to  run  the  demonstration  on  the  MDSC  VAX: 
1.  Logon  as  user  SOFTECHl,  password  GREENE. 


2.  Type:  RUN  UOBJ; CAIS_LOGON  to  logon  to  the  CAIS. 

Specify  user  ITCF_DEMO,  password  ITCF_DEMO. 

3.  Wait  for  the  prompt  "file?".  This  may  take  a  minute, 

4 .  Type  the  name  of  a  VMS  file  to  read  into  the  buffer 
or 

6.  Type  a  carriage  return  to  start  an  empty  buffer. 

7.  Type  "H"  (help)  and  "S"  (summary)  for  an  editor  command  summary. 

8.  Type  "A"  (append)  to  enter  an  Ada  program  from  the  keyboard. 

Type  " . "  CR  to  end  input  mode . 

9.  Type  "L"  (list)  "A"  (all)  to  list  the  editor  buffer  contents. 

10.  Type  "C"  (center)  to  poll  the  tools  connected  to  the  ITCF 
connection  center.  The  names  of  the  tools  will  be  printed. 

11.  Type  "Z"  to  send  the  editor  buffer  to  the  Formatter  tool. 

A  new.  buffer  will  be  returned. 

12.  Type  "B"  (buffer  switch)  to  toggle  back  to  the  unformatted 
buffer. 

13.  Type  "K"  to  send  the  editor  buffer  to  the  Ada  statement  counter. 
The  number  of  Ada  statements,  blank  lines,  comment  lines  etc. 
will  be  printed. 

14.  If  CONTROL-Y  must  be  typed,  refresh  the  database  before  logging 
into  the  CAIS  again,  as  follows: 

Type  CONTROL-Y 
Type  STOP 
Type  (aREFRESH 


8 .  Unimplemented  Features 

Not  all  features  of  the  ITCF  were  implemented  under  this  task.  Only  the 
core  facilities  required  for  the  demonstration  were  fully  implemented.  In 
particular,  the  following  ITCF  packages  were  not  implemented: 

Package  Binary_Stream_IO  -  protocol  for  transmitting  Ada  data 

structures  in  a  compact  binary  form. 

Package  Sequential_Stream_IO  -  an  ITCF  version  of  Ada's  Sequential_IO . 

Package  Message_IO  -  a  generic  package  for  the  convenient 

encoding  and  decoding  of  short  streams. 

Also,  the  capability  to  connect  together  several  connection  centers  was  not 
implemented.  This  feature  is  useful  primarily  in  the  implementation 
connections  between  different  hosts,  e.g.  to  support  remote  procedure  calls 
among  a  network  of  loosely  coupled  hosts. 


9.  Conclusions  and  Lessons  Learned 

This  successful  implementation  and  demonstration  of  the  ITCF  proves  that 
the  ITCF  concept  is  workable  and  that  it  has  practical  applications. 
Although  the  demonstration  tools  (especially  the  line  editor)  may  not  be 
heavily  used  in  a  real  SEE,  the  same  principles  applied  to  adapt  these 
tools  could  be  applied  to  more  popular  screen  editors  and  more 
sophisticated  source  reformatters  and  other  source  analysis  tools. 


The  extension  of  a  tool  (such  as  an  editor)  through  exploitation  of  the 
functionality  of  other  tools  certainly  appears  worth  pursuing.  Such 
extensions  of  functionality  through  integration  of  independent  tools  has 
several  advantages.  In  the  sample  demonstration,  tool  functionality  is 
made  more  accessible  to  the  user.  Without  the  use  of  ITCF  integration,  the 
user  wishing  to  reformat  his  source  program  (under  development)  is  forced 
to  exit  the  editor,  type  a  lengthy  command  to  invoke  the  reformatter 
specifying  the  location  of  the  program  to  be  reformatted  and  the  location 
for  the  resulting  output  (which  may  be  subsequently  discarded).  The  user 
must  examine  the  results  and  then  re-invoke  the  editor  to  continue 
development  of  the  source  program.  Such  obstacles  to  tool  usage  (in  this 
case  the  use  of  the  reformatter)  are  likely  to  leave  such  tools 
underutilized  or  even  unutilized.  On  the  other  hand,  with  integration 
through  the  ITCF,  the  reformatting  function  becomes  immediately  available 
without  exiting  the  editor.  Only  a  simple  command  need  be  typed;  the 
source  is  reformatted  and  immediately  available  for  further  inspection  and 
editing. 

Similarly,  a  user  of  the  editor  may  wish  to  know  if  he  has  exceeded  the 
source  code  development  guidelines  of  his  project  (which  require  that  Ada 
procedures  contain  less  than  50  statements)  as  he  is  actually  typing  the 
procedure.  If  the  user  must  exit  the  editor  session  in  order  to  use  the  Ada 
statement  counter  tool,  then  the  statement  counter  tool  will  be  much  less 
useful  to  him. 

In  addition  to  the  user  convenience  which  ITCF  integration  may  provide, 
there  are  other  advantages.  Tools  which  are  integrated  through  the  ITCF 
are  still  independent  of  one  another.  They  can  be  linked  and  maintained 
independently  of  one  another.  Separately  linked  tools  integrated  through 
ITCF  occupy  less  memory  than  would  be  required  if  the  tools  were 
integrating  by  linking  them  into  common  memory  images.  Moreover,  due  to 
naming  conflicts  in  independently  developed  tools,  such  linking  is  not 
always  possible. 

When  a  shared  connection  center  with  server  tools  is  used  by  several  users, 
each  server  tool  is  represented  as  a  single,  serially  reusable  process. 

This  has  several  advantages.  The  tool  images  (even  if  non-reentrant)  are 
represented  only  once  in  memory.  The  number  of  processes  which  must  be 
managed  by  the  underlying  system  is  smaller.  The  tool  images  are  not 
reloaded  from  disk  each  time  they  are  invoked.  The  tool  elaboration  and 
other  tool  initialization  is  performed  only  once  for  all  users. 

A  typical  problem  in  shared  processing  environments  is  the  use  of  large, 
resource-intensive  tools  (such  as  an  Ada  compiler)  by  several  users 
concurrently.  Sometimes  as  few  as  two  concurrent  invocations  of  such  tools 
can  drastically  reduce  system  through-put  due  to  contention  for  memory, 
processing,  and  10  resources.  The  ITCF  can  be  used  (as  demonstrated)  to 
conveniently  serialize  access  to  such  tools  in  order  to  maximize 
through-put  in  these  types  of  environments.  For  example,  a  common 
connection  center  could  used  by  all  CLI  processes  to  serialize  the  use  of 
the  compiler  and  other  tools. 


10 .  Future  Applications 

The  connection  center  and  other  concepts  employed  in  the  ITCF  are 
relatively  new.  The  potential  applications  are  as  yet  not  fully  defined. 
The  design  and  implementation  of  the  ITCF  have  been  done  with  flexibility 
uppermost  in  order  that  the  potential  of  this  tool  not  be  limited  to 
specific  integration  scenarios  that  happened  to  be  envisioned  by  the 
ITCF  designers  and  implementers . 

Other  practical  application  scenarios  should  be  investigated  as  the  STARS 
program  continues.  There  may  be  many  as  yet  uninvestigated  applications. 
One  path  toward  wider  application  would  be  to  make  the  ITCF  facilities  more 
readily  available  at  the  Command  Line  Interpreter  level  of  the  environment. 


This  could  be  accomplished  by  implementing  the  ITCF  mechanisms  which 
support  RPC  (remote  procedure  call)  and  then  integrating  the  ITCF 
functionality  into  ACE  (the  Ada  Command  Environment), 

Another  area  for  application  ''f  the  ITCF  could  be  application  program 
development  and  testing.  The  use  of  software- first  methodologies  will  lead 
to  the  need  to  test  applicatioi,  software  within  the  software  development 
environment  before  the  target  hardware  is  available.  Many  applications  to 
be  developed  are  real-time  systems  utilizing  tasks  that  respond  to  incoming 
"streams"  of  environmental  date.  There  is  clearly  potential  here  to  use 
the  ITCF  to  create  simulated  environments  and  to  monitor  and. record 
responses.  There  is  even  the  tossibility  of  direct  use  of  ITCF  stream 
management  facilities  in  the  applications  themselves  as  a  means  of 
efficient  inter-task  communication  and  transient  data  management. 
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The  demonstration  tools,  tool  adaption,  problems  and  results  are  all 
documented  in  Section  7  of  the  ITCF  Final  Report.  Demonstration 
software  can  be  found  in  directories  under  the  following  root 
directory  on  the  MDSC  VAX: 


SYS$USER7 [SOFTECHl . USERS . SABBUHL. ITCF] 


